New pathfinding algorithm Oxyd Last week we mentioned the change to make biters not collide with each other, but that wasn’t the only biter-related update we released this past week. Somewhat coincidentally, this week’s updates have included something I’d been working on for a few weeks before – an upgrade to the enemy pathfinding system.
Map editor Lua snippets wheybags In the last few weeks, we've really accelerated our work on the campaign. We've been pushing ahead a lot with both the scripting and blocking out the physical level design. One of the problems we've come up against a lot, is that we often need to perform custom edits to the map, which are quite tedious, but not common enough to add a new tool to the map editor for them. For example, something like "disable all the spawners in this region". This kind of problem is easily solved with a little bit of custom Lua code, but getting the specification of the area we want to edit into Lua is a painful process of noting down and typing out location coordinates. It is also easy to lose track of these Lua snippets, as there is no good place to save them. To solve this problem, we decided to add a Lua snippet tool to the map editor. This tool will let you drag your cursor over an area, and it will then run your custom Lua code on that area. The snippets are named, and saved in your player-data.json, so you can keep them around for later. For example, this simple snippet replaces trees with biters. Currently, there doesn't seem to be a very big scene for community made custom maps/scenarios with custom maps, and we're hoping that the example from the campaign once released, as well as the much improved editor we have in 0.17 will encourage more people to give this a go.
New test servers We recently bought and assembled some high-end PCs, with the hope to gauge performance, speed up running tests, and potentially consolidate the number of servers we are maintaining internally. The two lucky CPUs were a i9-9980XE 18-core and a Ryzen 3900X 12-core. We are using the time to complete our test suite in 'heavy mode' as a benchmark. Heavy mode basically saves and reloads the game each tick, and compares a CRC of the map from before and after. It is super slow to run, but the heavy test is critical to help find any possible determinism issues. There is some more info on 'heavy mode' in FFF-63. As a baseline, the 'standard' CPU in the office for developers is the i9-7900x 10-core, which runs heavy tests in about 530 seconds. In real time this is 8 minutes and 50 seconds, a long time for a team member to sit around for results before they can push. We can do better! As you would expect, the new 18-core was blazing fast, with a test time of about 400 seconds, shaving off over 2 minutes. However the Ryzen was a different story, with a test time of about 600 seconds. This goes against what we predicted, where more cores and higher frequency mean lower test times. The initial results from the 12-core Ryzen were worse than from the 10-core Intel; not a good start. So I did some digging and some research, and the answer I arrived at was RAM. When we ordered the parts, not much thought was given to the selection of RAM, just some standard 16GB 2666MHz sticks to fill all the slots. Luckily, I looked on a local Czech website, and they had some stock of the brand new G.SKILL 3600MHz Trident RGB Neo, a high performance RAM stick made exactly to suit our new Ryzen CPU. After installing the new RAM, we had a test result that better matched our expectations: 450 seconds. We knew beforehand that Ryzen liked fast RAM, but we didn't realize how significant of a difference it could make. So now we have set up both these new machines to run tests automatically after each commit, and we are very happy with the result. The new i9-9980XE can compile and run heavy tests faster than our old i7-4790K can compile and run just normal tests. Having it run automatically also frees up individual developers from the responsibility of running heavy tests locally, so they can just push as normal and continue working.
Hello, technically this post is the π Friday Facts, but unfortunately we can't think of anything special to do... maybe someone can make a Combinator cake... that can calculate π?
Hello, We have had quite a peaceful week here in the office. Last night we went out for a burger and a beer as a last meal with Ernestas before he flies back home for another few months. It was also quite nostalgic, as we went to a place that we used to go to frequently near our old office, and the staff still remembered us.
Hello, we had a party last night in the office to celebrate the work we have done over the last 6 months on 0.17 stablisation. It was nice to have most of the team together to share some beers and pizza.
Hello, We had a lovely surprise waiting us this Monday, one of our fans had sent us a delicious cake: It didn't last very long... Thank you very much Conn! It certainly helped with the bug fixing push this week.
Hello, We are down to 28 bugs on the forum. The last bugs are often the ones we have been putting off for a reason, they generally require some more meaningful changes and decisions. That is why this week we have a lot to discuss.
Under 100 bugs We have a record low in our bug report forum, of only 55 active bug reports. I don't think in the history of Factorio the bug forum has been so clean. No doubt once we mark 0.17 as stable the count will shoot up again. For this weeks graph I added the count of players on Steam as the left axis. We thought it would be somewhat interesting to see if there is any correlation between the two. Note: The axis have different scales. I also prepared the same graph but for the duration of the 0.17 release. You can see our player numbers are dropping quite a lot, from the all time peak of 22,457 on the 3rd of March 2019. While bug reports might be at an all time low, we are not going to call the game stable yet. We still have an important milestone to reach, that is, implementing the new Introduction campaign graphics (FFF-301). A lot of the team has been on vacation these last few weeks, including the whole campaign team and most of the art department. What this means is that we expect it will be a few more weeks before we can call the current version stable. We have been asked a few times when stable will be released, but my question is, why does it matter exactly which version we call stable? Are you waiting for stable to play a new playthrough? The thing is, this stable is only going to be the 'first' stable. Our plan is to have a number of short experimental phases after the first stable, where we will add new GUI's and such, which will add bugs and technical debt. After fixing the bugs in a 'small' experimental content release, we will then mark that as the 'new' 0.17 stable. Besides, there are still a few edge cases with signals that kovarex is busy fixing: For instance the setup above took him 3 hours to fix. The cause of the issue was that the segment has both an incoming and outgoing signal at the same position.
The multiplayer megapacket Twinsen Last month I joined KatherineOfSky's MMO event as a player. I noticed that after we reached a certain number of players, every few minutes a bunch of them got dropped. Luckily for you (but unluckily for me), I was one of the players who got disconnected every, single. time, even though I had a decent connection. So I took the matter personally and started looking into the problem. After 3 weeks of debugging, testing and fixing, the issue is finally fixed, but the journey there was not that easy. Multiplayer issues are very hard to track down. Usually they only happen under very specific network conditions, in very specific game conditions (in this case having more than 200 players). Even when you can reproduce the issue it's impossible to properly debug, since placing a breakpoint stops the game, messes up the timers and usually times out the connection. But through some perseverance and thanks to an awesome tool called clumsy, I managed to figure out what was happening. The short version is: Because of a bug and an incomplete implementation of the latency state simulation, a client would sometimes end up in a situation where it would send a network package of about 400 entity selection input actions in one tick (what we called 'the megapacket'). The server then not only has to correctly receive those input actions but also send them to everyone else. That quickly becomes a problem when you have 200 clients. It quickly saturates the server upload, causes packet loss and causes a cascade of re-requested packets. Delayed input actions then cause more clients to send megapackets, cascading even further. The lucky clients manage to recover, the others end up being dropped. The issue was quite fundamental and took 2 weeks to fix. It's quite technical so I'll explain in juicy technical details below. But what you need to know is that since Version 0.17.54 released yesterday, multiplayer will be more stable and latency hiding will be much less glitchy (less rubber banding and teleporting) when experiencing temporary connection problems. I also changed how latency hiding is handled in combat, hopefully making it look a bit smoother.
